-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JCB-based obs+bias staging, Jedi class updates, and marine B-matrix refactoring #2992
base: develop
Are you sure you want to change the base?
JCB-based obs+bias staging, Jedi class updates, and marine B-matrix refactoring #2992
Conversation
…e bias correction files from tarball (NOAA-EMC#2862)
…on files using jedi class (NOAA-EMC#2862)
…ns analysis scripts (NOAA-EMC#2862)
@guillaumevernieres and @AndrewEichmann-NOAA , FYI, I'm rolling the marine B-matrix refactoring into this PR since that refactoring depends on the changes made to the The relevant files changed for the B-matrix refactoring are: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Thanks @DavidNew-NOAA .
Description
This PR is a companion to GDASApp PR #1312 (merged) and JCB-GDAS PR #31 (merged).
This PR does four things:
initialize_jedi
andexecute
methods from theAtmAnalysis
andAtmEnsAnalysis
classes and has that functionality handled directly by theJedi
class. This removes a lot of redundant code from the analysis classes.Jedi
constructor now takes as input a dictionary that is a subset of thetask_config
dictionary. This makes the code clearer and less opaque and makes debugging easier.AtmAnalysis
andAtmEnsAnalysis
. Before, in theatmensanl*
jobs for example, the LETKF solver was initialized in theatmensanlinit
cjob, but the LETKF solver and FV3 increment converter were both initialized and executed in theatmensanlobs
andatmensanlfv3inc
jobs respectively. This was because theJedi
class was looking for theJEDIEXE
,JCB_ALGO_YAML
, etc environment variables, which could only hold information for one application per job. Now, there are variables calledJEDIEXE_OBS
,JEDIEXE_SOL
,JEDIEXE_FV3INC
, etc which are specified in the input dictionary for theJedi
class constructor, all performed inatmensanlinit
. This not only makes more sense in terms of resources allocation for jobs, but it also makes the code less opaque.Addendum:
I'm now rolling in the refactoring of the marine B-matrix task into this PR. That makes it also a companion of GDASApp PR #1346 and JCB-GDAS PR #36.
These new changes introduce the
Jedi
class and JCB into the marine B-matrix job.Type of change
Change characteristics
How has this been tested?
C96C48_ufs_hybatmDA CI runs successfully
GDASApp jjob tests pass successfully
Checklist